<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
                      "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
    <meta http-equiv="content-type" content="text/html; charset=UTF-8"/>
    <title>Zend_XmlRpc_Server - Zend Framework Manual</title>

    <link href="../css/shCore.css" rel="stylesheet" type="text/css" />
    <link href="../css/shThemeDefault.css" rel="stylesheet" type="text/css" />
    <link href="../css/styles.css" media="all" rel="stylesheet" type="text/css" />
</head>
<body>
<h1>Zend Framework</h1>
<h2>Programmer's Reference Guide</h2>
<ul>
    <li><a href="../en/zend.xmlrpc.server.html">Inglês (English)</a></li>
    <li><a href="../pt-br/zend.xmlrpc.server.html">Português Brasileiro (Brazilian Portuguese)</a></li>
</ul>
<table width="100%">
    <tr valign="top">
        <td width="85%">
            <table width="100%">
                <tr>
                    <td width="25%" style="text-align: left;">
                    <a href="zend.xmlrpc.client.html">Zend_XmlRpc_Client</a>
                    </td>

                    <td width="50%" style="text-align: center;">
                        <div class="up"><span class="up"><a href="zend.xmlrpc.html">Zend_XmlRpc</a></span><br />
                        <span class="home"><a href="manual.html">Guia de Refer&ecirc;ncia do Programador</a></span></div>
                    </td>

                    <td width="25%" style="text-align: right;">
                        <div class="next" style="text-align: right; float: right;"><a href="requirements.html">Pr&eacute;-requisitos do Zend Framework</a></div>
                    </td>
                </tr>
            </table>
<hr />
<div id="zend.xmlrpc.server" class="section"><div class="info"><h1 class="title">Zend_XmlRpc_Server</h1></div>
    

    <div class="section" id="zend.xmlrpc.server.introduction"><div class="info"><h1 class="title">Introduction</h1></div>
        

        <p class="para">
            <span class="classname">Zend_XmlRpc_Server</span> is intended as a fully-featured
            <acronym class="acronym">XML-RPC</acronym> server, following <a href="http://www.xmlrpc.com/spec" class="link external">&raquo; the
                specifications outlined at www.xmlrpc.com</a>. Additionally, it implements the
            <strong class="command">system.multicall()</strong> method, allowing boxcarring of requests.
        </p>
    </div>

    <div class="section" id="zend.xmlrpc.server.usage"><div class="info"><h1 class="title">Basic Usage</h1></div>
        

        <p class="para">
            An example of the most basic use case:
        </p>

        <pre class="programlisting brush: php">
$server = new Zend_XmlRpc_Server();
$server-&gt;setClass(&#039;My_Service_Class&#039;);
echo $server-&gt;handle();
</pre>

    </div>

    <div class="section" id="zend.xmlrpc.server.structure"><div class="info"><h1 class="title">Server Structure</h1></div>
        

        <p class="para">
            <span class="classname">Zend_XmlRpc_Server</span> is composed of a variety of components,
            ranging from the server itself to request, response, and fault objects.
        </p>

        <p class="para">
            To bootstrap <span class="classname">Zend_XmlRpc_Server</span>, the developer must attach one or
            more classes or functions to the server, via the
             <span class="methodname">setClass()</span> and  <span class="methodname">addFunction()</span> methods.
        </p>

        <p class="para">
            Once done, you may either pass a <span class="classname">Zend_XmlRpc_Request</span>
            object to  <span class="methodname">Zend_XmlRpc_Server::handle()</span>, or it will
            instantiate a <span class="classname">Zend_XmlRpc_Request_Http</span> object if none
            is provided -- thus grabbing the request from
            <var class="filename">php://input</var>.
        </p>

        <p class="para">
             <span class="methodname">Zend_XmlRpc_Server::handle()</span> then attempts to
            dispatch to the appropriate handler based on the method
            requested. It then returns either a
            <span class="classname">Zend_XmlRpc_Response</span>-based object or a
            <span class="classname">Zend_XmlRpc_Server_Fault</span>object. These objects both have
             <span class="methodname">__toString()</span> methods that create valid
            <acronym class="acronym">XML-RPC</acronym> <acronym class="acronym">XML</acronym> responses, allowing them to be
            directly echoed.
        </p>
    </div>

    <div class="section" id="zend.xmlrpc.server.anatomy"><div class="info"><h1 class="title">Anatomy of a webservice</h1></div>
        

        <div class="section" id="zend.xmlrpc.server.anatomy.general"><div class="info"><h1 class="title">General considerations</h1></div>
            

            <p class="para">
                For maximum performance it is recommended to use a simple
                bootstrap file for the server component. Using
                <span class="classname">Zend_XmlRpc_Server</span> inside a
                <a href="zend.controller.html" class="link"><span class="classname">Zend_Controller</span></a>
                is strongly discouraged to avoid the overhead.
            </p>

            <p class="para">
                Services change over time and while webservices are generally
                less change intense as code-native <acronym class="acronym">APIs</acronym>, it
                is recommended to version your service. Do so to lay grounds to
                provide compatibility for clients using older versions of your
                service and manage your service lifecycle including deprecation
                timeframes.To do so just include a version number into your
                <acronym class="acronym">URI</acronym>. It is also recommended to include the
                remote protocol name in the <acronym class="acronym">URI</acronym> to allow easy
                integration of upcoming remoting technologies.
                http://myservice.ws/<em class="emphasis">1.0/XMLRPC/</em>.
            </p>
        </div>

        <div class="section" id="zend.xmlrpc.server.anatomy.expose"><div class="info"><h1 class="title">What to expose?</h1></div>
            

            <p class="para">
                Most of the time it is not sensible to expose business objects
                directly. Business objects are usually small and under heavy
                change, because change is cheap in this layer of your
                application. Once deployed and adopted, web services are hard to
                change. Another concern is <acronym class="acronym">I/O</acronym> and latency:
                the best webservice calls are those not happening. Therefore
                service calls need to be more coarse-grained than usual business
                logic is. Often an additional layer in front of your business
                objects makes sense. This layer is sometimes referred to as <a href="http://martinfowler.com/eaaCatalog/remoteFacade.html" class="link external">&raquo; Remote
                    Facade</a>.
                Such a service layer adds a coarse grained interface on top of
                your business logic and groups verbose operations into smaller
                ones.
            </p>
        </div>
    </div>

    <div class="section" id="zend.xmlrpc.server.conventions"><div class="info"><h1 class="title">Conventions</h1></div>
        

        <p class="para">
            <span class="classname">Zend_XmlRpc_Server</span> allows the developer to attach functions and
            class method calls as dispatchable <acronym class="acronym">XML-RPC</acronym> methods. Via
            <span class="classname">Zend_Server_Reflection</span>, it does introspection on all attached
            methods, using the function and method docblocks to determine the
            method help text and method signatures.
        </p>

        <p class="para">
            <acronym class="acronym">XML-RPC</acronym> types do not necessarily map one-to-one to
            <acronym class="acronym">PHP</acronym> types. However, the code will do its best to guess the
            appropriate type based on the values listed in @param and @return lines. Some
            <acronym class="acronym">XML-RPC</acronym> types have no immediate <acronym class="acronym">PHP</acronym> equivalent,
            however, and should be hinted using the <acronym class="acronym">XML-RPC</acronym> type in the PHPDoc.
            These include:
        </p>

        <ul class="itemizedlist">
            <li class="listitem">
                <p class="para">
                    <em class="emphasis"><span class="property">dateTime.iso8601</span></em>, a string formatted
                    as &#039;<strong class="command">YYYYMMDDTHH:mm:ss</strong>&#039;
                </p>
            </li>

            <li class="listitem"><p class="para"><em class="emphasis">base64</em>, base64 encoded data</p></li>

            <li class="listitem"><p class="para"><em class="emphasis">struct</em>, any associative array</p></li>
        </ul>

        <p class="para">
            An example of how to hint follows:
        </p>

        <pre class="programlisting brush: php">
/**
* This is a sample function
*
* @param base64 $val1 Base64-encoded data
* @param dateTime.iso8601 $val2 An ISO date
* @param struct $val3 An associative array
* @return struct
*/
function myFunc($val1, $val2, $val3)
{
}
</pre>


        <p class="para">
            PhpDocumentor does no validation of the types specified for params
            or return values, so this will have no impact on your <acronym class="acronym">API</acronym>
            documentation. Providing the hinting is necessary, however, when the
            server is validating the parameters provided to the method call.
        </p>

        <p class="para">
            It is perfectly valid to specify multiple types for both params and
            return values; the <acronym class="acronym">XML-RPC</acronym> specification even suggests that
            system.methodSignature should return an array of all possible method
            signatures (i.e., all possible combinations of param and return
            values). You may do so just as you normally would with
            PhpDocumentor, using the &#039;|&#039; operator:
        </p>

        <pre class="programlisting brush: php">
/**
* This is a sample function
*
* @param string|base64 $val1 String or base64-encoded data
* @param string|dateTime.iso8601 $val2 String or an ISO date
* @param array|struct $val3 Normal indexed array or an associative array
* @return boolean|struct
*/
function myFunc($val1, $val2, $val3)
{
}
</pre>


        <blockquote class="note"><p><b class="note">Note</b>: 
            <p class="para">
                Allowing multiple signatures can lead to confusion for developers
                using the services; to keep things simple, a <acronym class="acronym">XML-RPC</acronym>
                service method should only have a single signature.
            </p>
        </p></blockquote>
    </div>

    <div class="section" id="zend.xmlrpc.server.namespaces"><div class="info"><h1 class="title">Utilizing Namespaces</h1></div>
        

        <p class="para">
            <acronym class="acronym">XML-RPC</acronym> has a concept of namespacing; basically, it allows grouping
            <acronym class="acronym">XML-RPC</acronym> methods by dot-delimited namespaces. This helps prevent
            naming collisions between methods served by different classes. As an
            example, the <acronym class="acronym">XML-RPC</acronym> server is expected to server several methods in
            the &#039;system&#039; namespace:
        </p>

        <ul class="itemizedlist">
            <li class="listitem"><p class="para">system.listMethods</p></li>
            <li class="listitem"><p class="para">system.methodHelp</p></li>
            <li class="listitem"><p class="para">system.methodSignature</p></li>
        </ul>

        <p class="para">
            Internally, these map to the methods of the same name in
            <span class="classname">Zend_XmlRpc_Server</span>.
        </p>

        <p class="para">
            If you want to add namespaces to the methods you serve, simply
            provide a namespace to the appropriate method when attaching a
            function or class:
        </p>

        <pre class="programlisting brush: php">
// All public methods in My_Service_Class will be accessible as
// myservice.METHODNAME
$server-&gt;setClass(&#039;My_Service_Class&#039;, &#039;myservice&#039;);

// Function &#039;somefunc&#039; will be accessible as funcs.somefunc
$server-&gt;addFunction(&#039;somefunc&#039;, &#039;funcs&#039;);
</pre>

    </div>

    <div class="section" id="zend.xmlrpc.server.request"><div class="info"><h1 class="title">Custom Request Objects</h1></div>
        

        <p class="para">
            Most of the time, you&#039;ll simply use the default request type included with
            <span class="classname">Zend_XmlRpc_Server</span>,
            <span class="classname">Zend_XmlRpc_Request_Http</span>. However, there may be times when you
            need <acronym class="acronym">XML-RPC</acronym> to be available via the <acronym class="acronym">CLI</acronym>, a
            <acronym class="acronym">GUI</acronym>, or other environment, or want to log incoming requests. To do
            so, you may create a custom request object that extends
            <span class="classname">Zend_XmlRpc_Request</span>. The most important thing to remember is to
            ensure that the  <span class="methodname">getMethod()</span> and
             <span class="methodname">getParams()</span> methods are implemented so that the
            <acronym class="acronym">XML-RPC</acronym> server can retrieve that information in order to dispatch the
            request.
        </p>
    </div>

    <div class="section" id="zend.xmlrpc.server.response"><div class="info"><h1 class="title">Custom Responses</h1></div>
        

        <p class="para">
            Similar to request objects, <span class="classname">Zend_XmlRpc_Server</span> can return custom
            response objects; by default, a <span class="classname">Zend_XmlRpc_Response_Http</span> object
            is returned, which sends an appropriate Content-Type <acronym class="acronym">HTTP</acronym> header for
            use with <acronym class="acronym">XML-RPC</acronym>. Possible uses of a custom object would be to log
            responses, or to send responses back to <b><tt>STDOUT</tt></b>.
        </p>

        <p class="para">
            To use a custom response class, use
             <span class="methodname">Zend_XmlRpc_Server::setResponseClass()</span> prior to calling
             <span class="methodname">handle()</span>.
        </p>
    </div>

    <div class="section" id="zend.xmlrpc.server.fault"><div class="info"><h1 class="title">Handling Exceptions via Faults</h1></div>
        

        <p class="para">
            <span class="classname">Zend_XmlRpc_Server</span> catches Exceptions generated by a dispatched
            method, and generates an <acronym class="acronym">XML-RPC</acronym> fault response when such an
            exception is caught. By default, however, the exception messages and
            codes are not used in a fault response. This is an intentional
            decision to protect your code; many exceptions expose more
            information about the code or environment than a developer would
            necessarily intend (a prime example includes database abstraction or
            access layer exceptions).
        </p>

        <p class="para">
            Exception classes can be whitelisted to be used as fault responses,
            however. To do so, simply utilize
             <span class="methodname">Zend_XmlRpc_Server_Fault::attachFaultException()</span> to pass an
            exception class to whitelist:
        </p>

        <pre class="programlisting brush: php">
Zend_XmlRpc_Server_Fault::attachFaultException(&#039;My_Project_Exception&#039;);
</pre>


        <p class="para">
            If you utilize an exception class that your other project exceptions
            inherit, you can then whitelist a whole family of exceptions at a
            time. <span class="classname">Zend_XmlRpc_Server_Exception</span>s are always whitelisted, to
            allow reporting specific internal errors (undefined methods, etc.).
        </p>

        <p class="para">
            Any exception not specifically whitelisted will generate a fault
            response with a code of &#039;404&#039; and a message of &#039;Unknown error&#039;.
        </p>
    </div>

    <div class="section" id="zend.xmlrpc.server.caching"><div class="info"><h1 class="title">Caching Server Definitions Between Requests</h1></div>
        

        <p class="para">
            Attaching many classes to an <acronym class="acronym">XML-RPC</acronym> server instance can utilize a
            lot of resources; each class must introspect using the Reflection
            <acronym class="acronym">API</acronym> (via <span class="classname">Zend_Server_Reflection</span>), which in
            turn generates a list of all possible method signatures to provide to the server class.
        </p>

        <p class="para">
            To reduce this performance hit somewhat, <span class="classname">Zend_XmlRpc_Server_Cache</span>
            can be used to cache the server definition between requests. When
            combined with  <span class="methodname">__autoload()</span>, this can greatly increase
            performance.
        </p>

        <p class="para">
            An sample usage follows:
        </p>

        <pre class="programlisting brush: php">
function __autoload($class)
{
    Zend_Loader::loadClass($class);
}

$cacheFile = dirname(__FILE__) . &#039;/xmlrpc.cache&#039;;
$server = new Zend_XmlRpc_Server();

if (!Zend_XmlRpc_Server_Cache::get($cacheFile, $server)) {
    require_once &#039;My/Services/Glue.php&#039;;
    require_once &#039;My/Services/Paste.php&#039;;
    require_once &#039;My/Services/Tape.php&#039;;

    $server-&gt;setClass(&#039;My_Services_Glue&#039;, &#039;glue&#039;);   // glue. namespace
    $server-&gt;setClass(&#039;My_Services_Paste&#039;, &#039;paste&#039;); // paste. namespace
    $server-&gt;setClass(&#039;My_Services_Tape&#039;, &#039;tape&#039;);   // tape. namespace

    Zend_XmlRpc_Server_Cache::save($cacheFile, $server);
}

echo $server-&gt;handle();
</pre>


        <p class="para">
            The above example attempts to retrieve a server definition from
            <span class="property">xmlrpc.cache</span> in the same directory as the script. If unsuccessful,
            it loads the service classes it needs, attaches them to the server
            instance, and then attempts to create a new cache file with the
            server definition.
        </p>
    </div>

    <div class="section" id="zend.xmlrpc.server.use"><div class="info"><h1 class="title">Usage Examples</h1></div>
        

        <p class="para">
            Below are several usage examples, showing the full spectrum of
            options available to developers. Usage examples will each build
            on the previous example provided.
        </p>

        <div class="example" id="zend.xmlrpc.server.use.attach-function"><div class="info"><p><b>Example #1 Basic Usage</b></p></div>
            

            <div class="example-contents"><p>
                The example below attaches a function as a dispatchable <acronym class="acronym">XML-RPC</acronym>
                method and handles incoming calls.
            </p></div>

            <pre class="programlisting brush: php">
/**
 * Return the MD5 sum of a value
 *
 * @param string $value Value to md5sum
 * @return string MD5 sum of value
 */
function md5Value($value)
{
    return md5($value);
}

$server = new Zend_XmlRpc_Server();
$server-&gt;addFunction(&#039;md5Value&#039;);
echo $server-&gt;handle();
</pre>

        </div>

        <div class="example" id="zend.xmlrpc.server.use.attach-class"><div class="info"><p><b>Example #2 Attaching a class</b></p></div>
            

            <div class="example-contents"><p>
                The example below illustrates attaching a class&#039; public methods
                as dispatchable <acronym class="acronym">XML-RPC</acronym> methods.
            </p></div>

            <pre class="programlisting brush: php">
require_once &#039;Services/Comb.php&#039;;

$server = new Zend_XmlRpc_Server();
$server-&gt;setClass(&#039;Services_Comb&#039;);
echo $server-&gt;handle();
</pre>

        </div>

        <div class="example" id="zend.xmlrpc.server.use.attach-class-with-arguments"><div class="info"><p><b>Example #3 Attaching a class with arguments</b></p></div>
            

            <div class="example-contents"><p>
                The following example illustrates how to attach a class&#039; public
                methods and passing arguments to its methods. This can be used to specify certain
                defaults when registering service classes.
            </p></div>

            <pre class="programlisting brush: php">
class Services_PricingService
{
    /**
     * Calculate current price of product with $productId
     *
     * @param ProductRepository $productRepository
     * @param PurchaseRepository $purchaseRepository
     * @param integer $productId
     */
    public function calculate(ProductRepository $productRepository,
                              PurchaseRepository $purchaseRepository,
                              $productId)
    {
        ...
    }
}

$server = new Zend_XmlRpc_Server();
$server-&gt;setClass(&#039;Services_PricingService&#039;,
                  &#039;pricing&#039;,
                  new ProductRepository(),
                  new PurchaseRepository());
</pre>


            <div class="example-contents"><p>
                The arguments passed at  <span class="methodname">setClass()</span> at server construction
                time are injected into the method call <strong class="command">pricing.calculate()</strong> on
                remote invokation. In the example above, only the argument
                <var class="varname">$purchaseId</var> is expected from the client.
            </p></div>
        </div>

        <div class="example" id="zend.xmlrpc.server.use.attach-class-with-arguments-constructor"><div class="info"><p><b>Example #4 Passing arguments only to constructor</b></p></div>
            

            <div class="example-contents"><p>
                <span class="classname">Zend_XmlRpc_Server</span> allows to restrict argument passing to
                constructors only. This can be used for constructor dependency injection.
                To limit injection to constructors, call
                 <span class="methodname">sendArgumentsToAllMethods</span> and pass
                <b><tt>FALSE</tt></b> as an argument. This disables the default behavior of all
                arguments being injected into the remote method. In the example below the instance
                of <span class="classname">ProductRepository</span> and
                <span class="classname">PurchaseRepository</span> is only injected into the constructor of
                <span class="classname">Services_PricingService2</span>.
            </p></div>

            <pre class="programlisting brush: php">
class Services_PricingService2
{
    /**
     * @param ProductRepository $productRepository
     * @param PurchaseRepository $purchaseRepository
     */
    public function __construct(ProductRepository $productRepository,
                                PurchaseRepository $purchaseRepository)
    {
        ...
    }

    /**
     * Calculate current price of product with $productId
     *
     * @param integer $productId
     * @return double
     */
    public function calculate($productId)
    {
        ...
    }
}

$server = new Zend_XmlRpc_Server();
$server-&gt;sendArgumentsToAllMethods(false);
$server-&gt;setClass(&#039;Services_PricingService2&#039;,
                  &#039;pricing&#039;,
                  new ProductRepository(),
                  new PurchaseRepository());
</pre>

        </div>

        <div class="example" id="zend.xmlrpc.server.use.attach-instance"><div class="info"><p><b>Example #5 Attaching a class instance</b></p></div>
            

            <div class="example-contents"><p>
                 <span class="methodname">setClass()</span> allows to register a previously instantiated
                object at the server. Just pass an instance instead of the class name. Obviously
                passing arguments to the constructor is not possible with pre-instantiated
                objects.
            </p></div>
        </div>

        <div class="example" id="zend.xmlrpc.server.use.attach-several-classes-namespaces"><div class="info"><p><b>Example #6 Attaching several classes using namespaces</b></p></div>
            

            <div class="example-contents"><p>
                The example below illustrates attaching several classes, each
                with their own namespace.
            </p></div>

            <pre class="programlisting brush: php">
require_once &#039;Services/Comb.php&#039;;
require_once &#039;Services/Brush.php&#039;;
require_once &#039;Services/Pick.php&#039;;

$server = new Zend_XmlRpc_Server();
$server-&gt;setClass(&#039;Services_Comb&#039;, &#039;comb&#039;);   // methods called as comb.*
$server-&gt;setClass(&#039;Services_Brush&#039;, &#039;brush&#039;); // methods called as brush.*
$server-&gt;setClass(&#039;Services_Pick&#039;, &#039;pick&#039;);   // methods called as pick.*
echo $server-&gt;handle();
</pre>

        </div>

        <div class="example" id="zend.xmlrpc.server.use.exceptions-faults"><div class="info"><p><b>Example #7 Specifying exceptions to use as valid fault responses</b></p></div>
            

            <div class="example-contents"><p>
                The example below allows any <span class="classname">Services_Exception</span>-derived
                class to report its code and message in the fault response.
            </p></div>

            <pre class="programlisting brush: php">
require_once &#039;Services/Exception.php&#039;;
require_once &#039;Services/Comb.php&#039;;
require_once &#039;Services/Brush.php&#039;;
require_once &#039;Services/Pick.php&#039;;

// Allow Services_Exceptions to report as fault responses
Zend_XmlRpc_Server_Fault::attachFaultException(&#039;Services_Exception&#039;);

$server = new Zend_XmlRpc_Server();
$server-&gt;setClass(&#039;Services_Comb&#039;, &#039;comb&#039;);   // methods called as comb.*
$server-&gt;setClass(&#039;Services_Brush&#039;, &#039;brush&#039;); // methods called as brush.*
$server-&gt;setClass(&#039;Services_Pick&#039;, &#039;pick&#039;);   // methods called as pick.*
echo $server-&gt;handle();
</pre>

        </div>

        <div class="example" id="zend.xmlrpc.server.use.custom-request-object"><div class="info"><p><b>Example #8 Utilizing custom request and response objects</b></p></div>
            

            <div class="example-contents"><p>
                Some use cases require to utilize a custom request object.
                For example, <acronym class="acronym">XML/RPC</acronym> is not bound to
                <acronym class="acronym">HTTP</acronym> as a transfer protocol. It is possible to use
                other transfer protocols like <acronym class="acronym">SSH</acronym> or telnet to send
                the request and response data over the wire. Another use case is
                authentication and authorization. In case of a different transfer
                protocol, one need to change the implementation to read request data.
            </p></div>

            <div class="example-contents"><p>
                The example below instantiates a custom request object and
                passes it to the server to handle.
            </p></div>

            <pre class="programlisting brush: php">
require_once &#039;Services/Request.php&#039;;
require_once &#039;Services/Exception.php&#039;;
require_once &#039;Services/Comb.php&#039;;
require_once &#039;Services/Brush.php&#039;;
require_once &#039;Services/Pick.php&#039;;

// Allow Services_Exceptions to report as fault responses
Zend_XmlRpc_Server_Fault::attachFaultException(&#039;Services_Exception&#039;);

$server = new Zend_XmlRpc_Server();
$server-&gt;setClass(&#039;Services_Comb&#039;, &#039;comb&#039;);   // methods called as comb.*
$server-&gt;setClass(&#039;Services_Brush&#039;, &#039;brush&#039;); // methods called as brush.*
$server-&gt;setClass(&#039;Services_Pick&#039;, &#039;pick&#039;);   // methods called as pick.*

// Create a request object
$request = new Services_Request();

echo $server-&gt;handle($request);
</pre>

        </div>

        <div class="example" id="zend.xmlrpc.server.use.custom-response-object"><div class="info"><p><b>Example #9 Specifying a custom response class</b></p></div>
            

            <div class="example-contents"><p>
                The example below illustrates specifying a custom response class
                for the returned response.
            </p></div>

            <pre class="programlisting brush: php">
require_once &#039;Services/Request.php&#039;;
require_once &#039;Services/Response.php&#039;;
require_once &#039;Services/Exception.php&#039;;
require_once &#039;Services/Comb.php&#039;;
require_once &#039;Services/Brush.php&#039;;
require_once &#039;Services/Pick.php&#039;;

// Allow Services_Exceptions to report as fault responses
Zend_XmlRpc_Server_Fault::attachFaultException(&#039;Services_Exception&#039;);

$server = new Zend_XmlRpc_Server();
$server-&gt;setClass(&#039;Services_Comb&#039;, &#039;comb&#039;);   // methods called as comb.*
$server-&gt;setClass(&#039;Services_Brush&#039;, &#039;brush&#039;); // methods called as brush.*
$server-&gt;setClass(&#039;Services_Pick&#039;, &#039;pick&#039;);   // methods called as pick.*

// Create a request object
$request = new Services_Request();

// Utilize a custom response
$server-&gt;setResponseClass(&#039;Services_Response&#039;);

echo $server-&gt;handle($request);
</pre>

        </div>
    </div>

    <div class="section" id="zend.xmlrpc.server.performance"><div class="info"><h1 class="title">Performance optimization</h1></div>
        

        <div class="example" id="zend.xmlrpc.server.performance.caching"><div class="info"><p><b>Example #10 Cache server definitions between requests</b></p></div>
            

            <div class="example-contents"><p>
                The example below illustrates caching server definitions between requests.
            </p></div>

            <pre class="programlisting brush: php">
// Specify a cache file
$cacheFile = dirname(__FILE__) . &#039;/xmlrpc.cache&#039;;

// Allow Services_Exceptions to report as fault responses
Zend_XmlRpc_Server_Fault::attachFaultException(&#039;Services_Exception&#039;);

$server = new Zend_XmlRpc_Server();

// Attempt to retrieve server definition from cache
if (!Zend_XmlRpc_Server_Cache::get($cacheFile, $server)) {
    $server-&gt;setClass(&#039;Services_Comb&#039;, &#039;comb&#039;);   // methods called as comb.*
    $server-&gt;setClass(&#039;Services_Brush&#039;, &#039;brush&#039;); // methods called as brush.*
    $server-&gt;setClass(&#039;Services_Pick&#039;, &#039;pick&#039;);   // methods called as pick.*

    // Save cache
    Zend_XmlRpc_Server_Cache::save($cacheFile, $server);
}

// Create a request object
$request = new Services_Request();

// Utilize a custom response
$server-&gt;setResponseClass(&#039;Services_Response&#039;);

echo $server-&gt;handle($request);
</pre>

        </div>

        <blockquote class="note"><p><b class="note">Note</b>: 
            <p class="para">
                The server cache file should be located outside the document root.
            </p>
        </p></blockquote>

        <div class="example" id="zend.xmlrpc.server.performance.xmlgen"><div class="info"><p><b>Example #11 Optimizing XML generation</b></p></div>
            

            <div class="example-contents"><p>
                <span class="classname">Zend_XmlRpc_Server</span> uses
                <span class="classname">DOMDocument</span> of <acronym class="acronym">PHP</acronym>
                extension <em class="emphasis">ext/dom</em> to generate it&#039;s
                <acronym class="acronym">XML</acronym> output. While <em class="emphasis">ext/dom</em> is
                available on a lot of hosts it is not exactly the fastest.
                Benchmarks have shown, that <span class="classname">XmlWriter</span>
                from <em class="emphasis">ext/xmlwriter</em> performs better.
            </p></div>

            <div class="example-contents"><p>
                If <em class="emphasis">ext/xmlwriter</em> is available on your host, you can
                select a the <span class="classname">XmlWriter</span>-based generator
                to leaverage the performance differences.
            </p></div>

            <pre class="programlisting brush: php">
require_once &#039;Zend/XmlRpc/Server.php&#039;;
require_once &#039;Zend/XmlRpc/Generator/XmlWriter.php&#039;;

Zend_XmlRpc_Value::setGenerator(new Zend_XmlRpc_Generator_XmlWriter());

$server = new Zend_XmlRpc_Server();
...
</pre>

        </div>

        <blockquote class="note"><p><b class="note">Note</b>: <span class="info"><b>Benchmark your application</b><br /></span>
            

            <p class="para">
                Performance is determined by a lot of parameters and
                benchmarks only apply for the specific test case. Differences
                come from <acronym class="acronym">PHP</acronym> version, installed extensions, webserver and
                operating system just to name a few. Please make sure to
                benchmark your application on your own and decide which
                generator to use based on <em class="emphasis">your</em> numbers.
            </p>
        </p></blockquote>

        <blockquote class="note"><p><b class="note">Note</b>: <span class="info"><b>Benchmark your client</b><br /></span>
            

            <p class="para">
                This optimization makes sense for the client side too. Just
                select the alternate <acronym class="acronym">XML</acronym> generator before
                doing any work with <span class="classname">Zend_XmlRpc_Client</span>.
            </p>
        </p></blockquote>
    </div>
</div>
        <hr />

            <table width="100%">
                <tr>
                    <td width="25%" style="text-align: left;">
                    <a href="zend.xmlrpc.client.html">Zend_XmlRpc_Client</a>
                    </td>

                    <td width="50%" style="text-align: center;">
                        <div class="up"><span class="up"><a href="zend.xmlrpc.html">Zend_XmlRpc</a></span><br />
                        <span class="home"><a href="manual.html">Guia de Refer&ecirc;ncia do Programador</a></span></div>
                    </td>

                    <td width="25%" style="text-align: right;">
                        <div class="next" style="text-align: right; float: right;"><a href="requirements.html">Pr&eacute;-requisitos do Zend Framework</a></div>
                    </td>
                </tr>
            </table>
</td>
        <td style="font-size: smaller;" width="15%"> <style type="text/css">
#leftbar {
	float: left;
	width: 186px;
	padding: 5px;
	font-size: smaller;
}
ul.toc {
	margin: 0px 5px 5px 5px;
	padding: 0px;
}
ul.toc li {
	font-size: 85%;
	margin: 1px 0 1px 1px;
	padding: 1px 0 1px 11px;
	list-style-type: none;
	background-repeat: no-repeat;
	background-position: center left;
}
ul.toc li.header {
	font-size: 115%;
	padding: 5px 0px 5px 11px;
	border-bottom: 1px solid #cccccc;
	margin-bottom: 5px;
}
ul.toc li.active {
	font-weight: bold;
}
ul.toc li a {
	text-decoration: none;
}
ul.toc li a:hover {
	text-decoration: underline;
}
</style>
 <ul class="toc">
  <li class="header home"><a href="manual.html">Guia de Refer&ecirc;ncia do Programador</a></li>
  <li class="header up"><a href="manual.html">Guia de Refer&ecirc;ncia do Programador</a></li>
  <li class="header up"><a href="reference.html">Refer&ecirc;ncia do Zend Framework</a></li>
  <li class="header up"><a href="zend.xmlrpc.html">Zend_XmlRpc</a></li>
  <li><a href="zend.xmlrpc.introduction.html">Introduction</a></li>
  <li><a href="zend.xmlrpc.client.html">Zend_XmlRpc_Client</a></li>
  <li class="active"><a href="zend.xmlrpc.server.html">Zend_XmlRpc_Server</a></li>
 </ul>
 </td>
    </tr>
</table>

<script type="text/javascript" src="../js/shCore.js"></script>
<script type="text/javascript" src="../js/shAutoloader.js"></script>
<script type="text/javascript" src="../js/main.js"></script>

</body>
</html>